home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0002.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  3.7 KB  |  79 lines
  1. You raise a number of interesting questions:
  2.  
  3. >   1. access to the host's quota control mechanism, where one exists
  4.  
  5. This is difficult to do in any sort of general way.  One problem is that
  6. different implementations have different interpretations of quotas.
  7.  
  8. On many systems, a quota is really some number of disk records (or clusters of
  9. disk records).  Users often don't know their real quota; they are told some
  10. number of `bytes' or `blocks' but they discover -- to their confusion -- that
  11. they are out of quota even though the total number of `bytes' or `blocks' is
  12. considerably less.
  13.  
  14. [Anecdote: A system I used 19 years ago gave users a `100 block' quota, saying
  15. this was 64,000 characters.  However, it actually allocated (and charged!) in
  16. clusters of 5 blocks, so the actual limit was 20 files, and only if the files
  17. were less than 3200 characters each -- a 3201 character file was charged as 10
  18. blocks.]
  19.  
  20. I agree that some mechanism to give users a handle on their disk quota
  21. remotely is necessary.  It is important that any mechanism picked *not* be
  22. biased towards on particular operating system's strategy, and that the data be
  23. useful for a user.  Another issue is scoping; IMAP must not be allowed to get
  24. `everything but the kitchen sink' put in, or we'll end up with an unwieldy
  25. mess.  This is one reason why only minimal management was put into IMAP2bis
  26. and why the more complex management issues were deferred to the Mail
  27. Management Protocol.
  28.  
  29. So, let's put this on the table as a topic.
  30.  
  31. Modern-day c-client does detect and clean up properly when quota problems hit.
  32.  
  33. >   2. password changing (for non-Kerberos sites)
  34.  
  35. I believe that this was going to be considered as part of the Mail Management
  36. Protocol developed by CMU.  I'd like to hear comments from the CMU hackers on
  37. this.  I think that an environment in which users do not log into the IMAP
  38. server as timesharing users will have to have the Mail Management Protocol
  39. layer; the IMAP-only environment is for the `simple' configurations.
  40.  
  41. >   3. forwarding (automatic, i.e. access to '.forward' file or equivalent)
  42.  
  43. This is also a Mail Management Protocol issue for the same reasons.  CMU???
  44.  
  45. >   4. simple X.500 interface
  46.  
  47. This is one of those things that everyone talks about a lot, but it isn't all
  48. that clear to me what it implies.  X.500 is supposed to solve all our problems
  49. but then again X.400 was supposed to do so too.  I don't think that `simple'
  50. and `X.anything' properly go together.  We'll need to do something about this,
  51. but I'm taking a `wait and see' attitude until I understand the issues better.
  52.  
  53. >   5. forwarding (user-initiated, i.e. in a session)
  54.  
  55. Could you explain this?  I don't quite understand what you mean.  Do you mean
  56. forwarding a message or altering your mail forwarding or ??
  57.  
  58. >   6. mail sending
  59.  
  60. This is a frequently asked request.  The IETF-REMMAIL group seems to have
  61. sputtered out on this question, without achieving closure.  There are strong
  62. arguments on both sides of the issue.  Although I am an `anti', I am
  63. sympathetic to the problems the `pro' side faces; however, I have been totally
  64. unsuccessful in playing Devil's Advocate for the `pro' side.
  65.  
  66. I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing
  67. the same points over again.  It's an emotional topic; the `pro' side is
  68. defending what they consider to be the side of simplicity (of a sort) and
  69. authentication (again, of a sort), while the `anti' side defends simplicity
  70. (of a different sort) and models which are possible only if mail access and
  71. mail posting are not coupled.
  72.  
  73. If possible, I would like to see the discussion of this topic take place on
  74. IETF-REMMAIL and not here.  I am agreeable to letting IMAP follow the
  75. concensus of the IETF-REMMAIL group, should they achieve closure on the topic.
  76.  
  77. -- Mark --
  78.  
  79.